Traduction de l’article original Unbound DNS Tutorial
Unbound est un serveur DNS récursif, de validation et de mise en cache très sûr, principalement développé par NLnet Labs, VeriSign Inc, Nominet et Kirei. Le logiciel est distribué gratuitement sous la licence BSD. Les binaires sont écrits avec une grande attention à la sécurité, un code C serré et un état d'esprit selon lequel il est toujours attaqué ou les serveurs distants essaient toujours de lui transmettre de mauvaises informations.
La conception d'Unbound est un ensemble de composants modulaires qui intègrent des caractéristiques telles que la validation de la sécurité renforcée (DNSSEC), la version 6 du protocole Internet (IPv6) et une API de bibliothèque de résolution de clients comme partie intégrante de l'architecture. Écrit à l'origine pour un système d'exploitation de type Unix compatible Posix, Unbound fonctionne actuellement sous FreeBSD, OpenBSD, NetBSD et Linux, ainsi que sous Microsoft Windows.
L'installation et la configuration d'Unbound est incroyablement simple. La plupart des systèmes d'exploitation modernes ont déjà fait des paquets Unbound. Nous avons vérifié qu'OpenBSD, FreeBSD, CentOS et Ubuntu ont des paquetages disponibles via leurs méthodes de distribution actuelles. Quant à la configuration, un simple serveur DNS de résolution de cache qui peut être utilisé pour une seule machine ou un réseau local multi-machine ne fait que quelques lignes. Notez qu'Unbound n'est pas un serveur faisant autorité à part entière, mais vous pouvez mettre des enregistrements A pour la résolution en avant et en arrière d'un petit réseau local privé.
À l'avenir, on s'attend à ce que de nombreuses, sinon toutes les distributions de logiciels libres passent à Unbound et s'éloignent de BIND. FreeBSD 10 a déjà effectué ce changement car BIND n'est plus inclus dans l'installation par défaut. BIND, également connu sous le nom de named, devient extrêmement gonflé de code, lent et trop compliqué. La complication conduit à des exploits de sécurité et plus de vingt (20) des soixante-dix (70) derniers bogues critiques de FreeBSD sont dus à BIND lui-même. L'autre problème est que BIND est utilisé pour environ 70% des serveurs DNS mondiaux, ce qui conduit à un environnement de monoculture. Lorsqu'une attaque ou un exploit se produit, il est avantageux pour l'attaquant de s'en prendre aux logiciels les plus utilisés. En comparaison, BIND est un serveur de noms DNS incroyablement rapide et sûr qui, en raison de sa petite taille, peut facilement faire l'objet d'un audit de sécurité du code.
Examinons quelques définitions et quelques exemples.
Avant d'examiner les exemples de configuration, nous devons comprendre les fonctions de base disponibles par un serveur DNS moderne. Vous pouvez ensuite décider quel type de serveur DNS vous souhaitez et passer directement aux configurations ci-dessous. Notez que vous pouvez combiner plusieurs fonctions ensemble dans un seul serveur DNS. Par exemple, vous pouvez avoir un serveur DNS de mise en cache, un serveur DNS de mise en cache récursif, un serveur DNS de mise en cache récursif de validation, un serveur DNS de mise en cache récursif de validation faisant autorité, etc.
Les serveurs de noms en cache stockent les résultats des requêtes DNS pendant une période de temps déterminée dans la configuration (time-to-live) de l'enregistrement du nom de domaine en question. Les serveurs de noms récursifs résolvent toute requête qu'ils reçoivent, même s'ils ne font pas autorité pour la question posée, en consultant le ou les serveurs qui font autorité pour la requête. La mise en cache des serveurs de noms, comme on le verra dans la section suivante, améliore l'efficacité du DNS en réduisant le trafic DNS sur l'Internet et en diminuant la charge des serveurs de noms faisant autorité, en particulier les serveurs de noms racine. Comme les serveurs DNS locaux peuvent répondre plus rapidement aux questions, ils augmentent également les performances des applications des utilisateurs finaux qui utilisent le DNS.
Un serveur DNS récursif parcourra, au nom du client (résolveur), les chemins du DNS sur l'Internet pour récupérer la réponse à la question. Une simple requête telle que "Quelle est l'adresse IP de calomel.org" à un serveur DNS qui prend en charge les requêtes récursives mais qui ne fait pas autorité pour calomel.org ressemblerait à ce qui suit :
- Le résolveur de votre client envoie une requête "Quelle est l'adresse IP de calomel.org" à un serveur DNS configuré localement comme Unbound.
- Le serveur DNS Unbound recherche calomel.org dans les tables locales (son cache) - non trouvé si nous n'avons jamais demandé ce nom d'hôte auparavant.
- Unbound DNS envoie une requête à l'un des serveurs racine dans son fichier root.hints.
- Le serveur racine répond en renvoyant aux serveurs du TLD ".org".
- Unbound envoie une requête "Quelle est l'adresse IP calomel.org" à l'un des serveurs du TLD .org.
- Le serveur TLD répond en renvoyant aux serveurs de noms faisant autorité pour calomel.org à DynDNS.org .
- Unbound envoie la requête "Quelle est l'adresse IP de calomel.org" à un serveur de noms faisant autorité pour calomel.org.
- Le fichier de zone faisant autorité chez DynDNS définit un enregistrement "A" qui contient l'adresse IP de calomel.org. DynDNS renvoie l'adresse IP de calomel.org .
- Unbound reçoit l'adresse ip de calomel.org et renvoie la réponse au résolveur du client. La transaction est terminée.
Comme vous pouvez le voir, une requête standard pour calomel.org est assez longue et demande un peu de temps. C'est pourquoi nous aimons garder une copie locale de la réponse sur notre serveur DNS local Unbound. Cette copie locale est appelée copie "en cache", ce qui nous amène à la section suivante.
Les serveurs de noms en cache, également appelés caches DNS, sont souvent aussi des serveurs de noms de résolution car ils effectuent toutes les étapes nécessaires pour répondre à toute requête DNS qu'ils reçoivent. Pour ce faire, le serveur de noms interroge chaque serveur de noms faisant autorité à tour de rôle, en commençant par la zone racine du DNS. Le processus d'interrogation se poursuit jusqu'à ce que Unbound atteigne le serveur faisant autorité pour la zone qui contient le nom de domaine interrogé. Cette combinaison de résolveur et de cache crée un serveur DNS qui répondra aux demandes de recherche en fournissant des réponses à partir de son cache si le nom d'hôte a déjà été demandé, ou en résolvant récursivement les noms d'hôtes si nous n'avons jamais vu ce nom d'hôte. Les résultats du cache sont renvoyés en une (1) ou deux (2) millisecondes, tandis que les requêtes récursives peuvent prendre des centaines de millisecondes ou plus.
Un serveur DNS de validation est simplement un résolveur qui vérifie que la réponse qu'il a reçue est aussi correcte qu'elle peut être sûre. Cette vérification est généralement effectuée à l'aide de Secure DNS (DNSSEC) ou en utilisant des bits aléatoires codés 0x20 dans la requête pour déjouer les tentatives d'usurpation. La validation peut également comprendre des contrôles de l'intégrité des données renvoyées ou s'assurer qu'un hôte distant n'essaie pas de renvoyer une adresse IP illégale pour un nom d'hôte externe (dnsspoof).
Pour effectuer une attaque d'empoisonnement du cache par exemple, l'attaquant exploite une faille dans le logiciel DNS. Si le serveur ne valide pas correctement les réponses DNS pour s'assurer qu'elles proviennent d'une source faisant autorité (par exemple en utilisant DNSSEC), le serveur finira par mettre en cache les entrées incorrectes localement et les servira à d'autres utilisateurs qui feront la même demande. Cela signifie simplement que lorsque vous tapez le nom d'hôte de votre banque, vous voulez vous assurer que ce nom d'hôte correspond à l'adresse IP réelle de votre banque et non à un site de phishing au Cap, en Afrique du Sud.
La paranoïa en matière de sécurité DNS est également une raison pour laquelle vous devez vraiment avoir confiance dans tout serveur de cache de résolution que vous ne contrôlez pas. Nous aimons avoir toujours un serveur DNS sous notre contrôle pour interroger les serveurs racine et remonter jusqu'au serveur faisant autorité du domaine. De cette façon, nous sommes sûrs de la configuration, car nous sommes les administrateurs, et nous avons confiance dans les serveurs DNS qui mettent en cache les données grâce à la conception de sécurité que nous avons mise en place. Si vous configurez votre résolveur DNS pour interroger le cache dns du FAI local, vous devez vraiment, vraiment faire confiance à son personnel et sa configuration est sécurisée. Du point de vue d'un attaquant, le cache dns d'un FAI est la cible parfaite. L'attaquant n'a besoin d'empoisonner qu'un seul serveur dns et toutes les requêtes de tous les utilisateurs de ce FAI vont aux machines compromises par l'attaquant. Ce scénario s'est déjà produit une fois pour les serveurs de cache DNS d'AT&T (google pour "dns attacks wild at&t") et il se reproduira malheureusement.
Un serveur DNS faisant autorité est simplement le propriétaire principal du nom d'hôte.
Lorsqu'un domaine est enregistré auprès d'un bureau d'enregistrement de noms de domaine, l'administrateur de zone fournit une liste de serveurs de noms (généralement au moins deux, pour des raisons de redondance) qui font autorité pour la zone qui contient le domaine. Le bureau d'enregistrement fournit les noms de ces serveurs au registre du domaine de premier niveau contenant la zone. Le registre du domaine configure à son tour les serveurs de noms faisant autorité pour ce domaine de premier niveau avec des délégations pour chaque serveur de la zone. Si le nom de domaine complet d'un serveur de noms pour une zone apparaît dans cette zone, l'administrateur de la zone fournit les adresses IP de ce serveur de noms, qui sont installées dans la zone mère sous forme d'enregistrements collés ; sinon, la délégation consiste en la liste des enregistrements NS pour cette zone.
Un serveur de noms indique que sa réponse fait autorité en définissant le bit Authoritative Answer (AA) dans la réponse à une requête sur un nom pour lequel il fait autorité. Les serveurs de noms qui fournissent des réponses pour lesquelles ils ne font pas autorité (par exemple, les serveurs de noms pour les zones mères), n'activent pas le bit AA.
Unbound peut être configuré pour fournir des noms faisant autorité pour un réseau local. Par exemple, si nous voulons que le nom d'hôte xbox360.home.lan soit résolu à l'adresse IP privée 10.0.0.3 .
CONSEIL : Assurez-vous de jeter un coup d'œil à notre script simple de vérification DNS. Il vérifiera la résolution des noms de votre réseau local en amont et en aval. C'est un moyen très rapide de vous assurer que votre configuration DNS est correcte.
La première étape consiste à installer Unbound. Nous vous suggérons d'installer Unbound via votre gestionnaire de paquets pour une installation facile et des mises à jour régulières de la version. La plupart des systèmes d'exploitation modernes ont des paquets pré-compilés (rpm, deb, tgz). Vous pouvez toujours installer Unbound à partir des sources si vous le souhaitez. Quelle que soit la méthode d'installation choisie, vous devez obtenir la version la plus récente possible. Voici quelques lignes de gestionnaire de paquets pour vous aider :
## FreeBSD 12
pkg install unbound (for libevent enabled Unbound)
-OR-
/usr/sbin/local-unbound (base install)
## FreeBSD 11 and earlier
portmaster dns/unbound
-OR-
pkg install unbound
## CentOS
yum install unbound
## Ubuntu
apt-get install unbound
## OpenBSD
pkg_add -i unbound
C'est l'exemple le plus simple, mais pleinement fonctionnel de Unbound et une solution parfaite pour un petit réseau local avec quelques centaines de machines accédant à Internet. La configuration interrogera les serveurs DNS publics pour obtenir les réponses faites par localhost ou ips sur le LAN à 10.0.0.0/8 et mettra les résultats en cache. Le niveau de journalisation est de 1(1), ce qui permet d'enregistrer les erreurs et d'imprimer les statistiques uniquement lorsque le démon Unbound est arrêté.
Remarquez que la zone d'avancée. Vous pouvez utiliser la directive forward-zone pour interroger les serveurs DNS de résolution. Par exemple, nous avons ici le Google Public DNS, le Quad9 et le Cloudflare DNS configurés. Vous pouvez remplacer ces ips par les serveurs DNS de votre FAI si vous le souhaitez.
Il vous suffit de vous assurer qu'Unbound est installé. Ensuite, placez le fichier unbound.conf suivant à la place de votre copie ; c'est-à-dire que sur l'installation d'OpenBSD, le fichier de configuration est situé dans /var/unbound/etc/unbound.conf , sur FreeBSD 10.0 et les versions antérieures /usr/local/etc/unbound/unbound.conf et FreeBSD 12 /var/unbound/unbound.conf ou /usr/local/etc/unbound/unbound.conf si installé à partir des pkg de FreeBSd. Ensuite, il suffit de lancer le démon unbound en fonction de votre système d'exploitation. C'est tout.
## Simple recursive caching DNS, UDP port 53
## unbound.conf -- https://calomel.org
#
server:
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
aggressive-nsec: yes
cache-max-ttl: 14400
cache-min-ttl: 1200
hide-identity: yes
hide-version: yes
interface: 0.0.0.0
prefetch: yes
rrset-roundrobin: yes
so-reuseport: yes
# tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt"
use-caps-for-id: yes
verbosity: 1
# Unbound from pkg built with libevent; increase threads and slabs to the
# number of real cpu cores to reduce lock contention. Increase cache size to
# store more records and allow each thread to serve an increased number of
# concurrent client requests.
# num-threads: 4
# msg-cache-slabs: 4
# rrset-cache-slabs: 4
# infra-cache-slabs: 4
# key-cache-slabs: 4
# msg-cache-size: 256M
# rrset-cache-size: 512M
# outgoing-range: 8192
# num-queries-per-thread: 4096
forward-zone:
name: "."
forward-addr: 1.0.0.1@53#one.one.one.one
forward-addr: 1.1.1.1@53#one.one.one.one
forward-addr: 8.8.4.4@53#dns.google
forward-addr: 8.8.8.8@53#dns.google
forward-addr: 9.9.9.9@53#dns.quad9.net
forward-addr: 149.112.112.112@53#dns.quad9.net
Comme pour le simple serveur de cache ci-dessus, assurez-vous que unbound est installé et localisez le chemin d'accès de unbound.conf dans votre distribution. Par exemple, sous FreeBSD 11 et 12, le fichier de configuration est placé sous /var/unbound/unbound.conf . La configuration suivante interrogera les serveurs DNS répertoriés sous la zone de transit en utilisant une connexion TLS cryptée sur le port 853. Unbound sur FreeBSD 12 est construit en fonction d'OpenSSL 1.1.1 qui supporte TLS 1.3 . La directive ssl-upstream indique à unbound de n'utiliser que TLS et de ne jamais envoyer de requêtes DNS en clair. TLS propose des hachages cryptographiques qui permettent de vérifier que les données en transit n'ont pas été modifiées, corrompues ou malicieusement réécrites. Pour plus d'informations, consultez le blog de l'APNIC sur la confidentialité des données DNS. Notez que le "DNS over TLS" est une simple requête DNS en format filaire TCP vers le port 853 utilisant le cryptage TLS, qui est différent du "DNS over HTTPS" qui est un appel http standard vers un serveur HTTPS sur le port 443 utilisant le cryptage TLS. Veillez à définir le chemin d'accès correct au fichier root.key pour la directive trust-anchor-file afin qu'unbound puisse valider (drapeau "ad") les requêtes DNSEEC ; par exemple, "drill -D calomel.org". La directive tls-cert-bundle doit pointer vers votre fichier de certificat racine local pour permettre à unbound de valider les connexions TLS. Sous FreeBSD, utilisez "pkg install ca_root_nss" pour installer le paquet de certificats racine du projet Mozilla.
NOTE : Pour que Unbound puisse valider le certificat du serveur DNS, le chemin d'accès au fichier "trust-anchor-file :" doit être défini pour votre système d'exploitation. Par exemple, l'emplacement par défaut du paquet de certificats racine est "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" sur Fedora, "/etc/ssl/certs/ca-certificats". crt" sur Debian/Ubuntu et le paquet de certificats publics de FreeBSD est situé à "/usr/local/share/certs/ca-root-nss.crt" après avoir installé le paquet de certificats publics de Mozilla en utilisant "pkg install ca_root_nss". Une fois que le paquet de certificats est défini, le format "forwardaddr" doit être l'adresse IP dns, "@", le numéro de port 853, "#", le nom d'hôte public valide du serveur DNS pour que le service de déconnexion puisse utiliser le paquet tls-cert-bundle pour valider le certificat du serveur dns. Sans le nom d'hôte public valide, les requêtes DNS sur TLS vers les serveurs DNS de Google échoueront avec une erreur similaire à "error : ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed".
## DNS Over TLS, Simple ENCRYPTED recursive caching DNS, TCP port 853
## unbound.conf -- https://calomel.org
## FreeBSD 12 unbound config
#
server:
access-control: 10.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
#access-control: fddd::/48 allow
aggressive-nsec: yes
#auto-trust-anchor-file: /usr/local/etc/unbound/root.key
cache-max-ttl: 14400
cache-min-ttl: 1200
chroot: /usr/local/etc/unbound
directory: /usr/local/etc/unbound
do-ip4: yes
do-ip6: yes
do-tcp: yes
hide-identity: yes
hide-version: yes
interface: 0.0.0.0
#interface: ::0
pidfile: /var/run/local_unbound.pid
port: 53
prefetch: yes
rrset-roundrobin: yes
so-reuseport: yes
tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt"
use-caps-for-id: yes
username: unbound
# Unbound from pkg built with libevent; increase threads and slabs to the
# number of real cpu cores to reduce lock contention. Increase cache size to
# store more records and allow each thread to serve an increased number of
# concurrent client requests.
# num-threads: 4
# msg-cache-slabs: 4
# rrset-cache-slabs: 4
# infra-cache-slabs: 4
# key-cache-slabs: 4
# msg-cache-size: 256M
# rrset-cache-size: 512M
# outgoing-range: 8192
# num-queries-per-thread: 4096
# forward-addr format must be ip "@" port number "#" followed by the valid public hostname
# in order for unbound to use the tls-cert-bundle to validate the dns server certificate.
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.0.0.1@853#one.one.one.one
forward-addr: 1.1.1.1@853#one.one.one.one
forward-addr: 8.8.4.4@853#dns.google
forward-addr: 8.8.8.8@853#dns.google
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
Cet exemple est un serveur DNS récursif de mise en cache, validant et faisant autorité, pleinement fonctionnel pour un réseau local privé et très proche de celui que nous utilisons personnellement. Unbound interrogera récursivement tout nom d'hôte des serveurs DNS racine dont il n'a pas de copie en cache. Il validera les requêtes à l'aide de DNSSEC et de bits aléatoires codés 0x20 pour déjouer les tentatives d'usurpation. Enfin, ce serveur sera le DNS faisant autorité pour quelques noms d'hôtes sur notre segment privé local "home.lan".
Pour commencer, il y a quelques étapes de configuration à suivre. La première consiste à obtenir une copie de la dernière liste du serveur DNS racine appelée root.hints. La seconde est d'obtenir la configuration de la clé de confiance DNSSEC de la racine. Troisièmement, vous devez configurer les noms d'hôtes et les adresses IP de votre réseau local. Ces étapes sont assez simples, alors commençons par les réaliser.
Cet exemple d'installation est pour OpenBSD. Le chemin d'installation est "/var/unbound/etc/" pour tous les fichiers de configuration. Vous pouvez placer les fichiers suivants n'importe où à condition d'indiquer à Unbound où ils résident. Ainsi, vous pouvez utiliser ceci comme exemple pour Ubuntu, RHEL et CentOS également.
Etape 1, "root-hints" : est le fichier qui contient la liste des serveurs DNS racine primaires. Unbound a bien une liste de serveurs DNS racine dans son code, mais nous voulons nous assurer que nous avons la copie la plus à jour. Nous mettons normalement notre copie à jour tous les six (6) mois.
Pour interroger un nom d'hôte, Unbound doit commencer en haut des serveurs DNS racine et descendre jusqu'aux serveurs faisant autorité (voir la définition d'un serveur DNS de résolution ci-dessus). Téléchargez une copie des indices de la racine à partir de l'Internic et placez-la dans le fichier /var/unbound/etc/root.hints. Ce fichier sera appelé par la directive root-hints : dans le fichier unbound.conf.
wget https://www.internic.net/domain/named.root -O /var/unbound/etc/root.hints
Etape 2, auto-trust-anchor-file : qui contient la clé du serveur racine afin que le DNSSEC puisse être validé. Nous devons dire à Unbound que nous faisons confiance au serveur racine afin qu'il puisse commencer à développer une chaîne de confiance jusqu'au nom d'hôte que nous voulons résoudre et valider en utilisant DNSSEC.
Pour cet exemple, nous créons un fichier dans "/var/unbound/etc/root.key" et nous y mettons la ligne suivante Il s'agit de l'ancre de confiance 2017 pour la zone racine. Vous pouvez vérifier indépendamment l'ancrage de la zone racine en allant dans le fichier IANA.org Index of /root-anchors.
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
Assurez-vous également que le fichier "/var/unbound/etc/root.key" est la propriété de l'utilisateur sous lequel le démon Unbound est exécuté. Notre utilisateur sur l'installation d'OpenBSD est "_unbound". Alors assurez-vous que l'utilisateur "_unbound" peut écrire dans le fichier.
Etape 3, les zones desservies localement sont les noms d'hôtes et les ips du réseau local pour lequel vous voulez qu'Unbound fasse autorité. Faites défiler le fichier unbound.conf et cherchez les directives local-zone, local-data et local-data-ptr. Il vous suffit de les modifier pour qu'elles correspondent aux noms des machines et aux adresses IP de votre réseau.
Dans l'exemple, nous avons le nom d'hôte firewall.home.lan qui se résout à l'adresse IP 10.0.0.1. Nous avons également une recherche inversée qui permet à l'adresse 10.0.0.1 de revenir au nom d'hôte firewall.home.lan. Il y en a d'autres, juste pour vous donner une bonne idée du format.
La préinstallation est terminée. Nous avons maintenant un fichier d'indices DNS des serveurs racine primaires. Nous avons également un fichier d'ancrage de confiance du serveur racine afin qu'Unbound puisse créer une chaîne de confiance pour DNSSEC. A l'avenir, au fur et à mesure que la clé DNS racine changera, Unbound mettra automatiquement à jour le fichier root.key pour nous. Enfin, nous avons quelques noms d'hôtes et ips de machines LAN que nous voulons résoudre de manière autoritaire.
Il suffit de s'assurer que le logiciel Unbound est installé. Ensuite, placez le fichier unbound.conf suivant à la place de votre copie ; c'est-à-dire que sur l'installation d'OpenBSD, il se trouve dans /var/unbound/etc/unbound.conf . Assurez-vous que les indices root et l'ancre de confiance sont en place comme indiqué dans les instructions ci-dessus. Ensuite, démarrez simplement le démon non lié en tapant "unbound". C'est tout.
## Authoritative, validating, recursive caching DNS
## unbound.conf -- https://calomel.org
#
server:
# log verbosity
verbosity: 1
# specify the interfaces to answer queries from by ip-address. The default
# is to listen to localhost (127.0.0.1 and ::1). specify 0.0.0.0 and ::0 to
# bind to all available interfaces. specify every interface[@port] on a new
# 'interface:' labeled line. The listen interfaces are not changed on
# reload, only on restart.
interface: 127.0.0.1
# port to answer queries from
port: 53
# Enable IPv4, "yes" or "no".
do-ip4: yes
# Enable IPv6, "yes" or "no".
do-ip6: no
# Enable UDP, "yes" or "no".
do-udp: yes
# Enable TCP, "yes" or "no". If TCP is not needed, Unbound is actually
# quicker to resolve as the functions related to TCP checks are not done.i
# NOTE: you may need tcp enabled to get the DNSSEC results from *.edu domains
# due to their size.
do-tcp: yes
# control which client ips are allowed to make (recursive) queries to this
# server. Specify classless netblocks with /size and action. By default
# everything is refused, except for localhost. Choose deny (drop message),
# refuse (polite error reply), allow (recursive ok), allow_snoop (recursive
# and nonrecursive ok)
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
# Read the root hints from this file. Default is nothing, using built in
# hints for the IN class. The file has the format of zone files, with root
# nameserver names and addresses only. The default may become outdated,
# when servers change, therefore it is good practice to use a root-hints
# file. get one from https://www.internic.net/domain/named.root
root-hints: "/var/unbound/etc/root.hints"
# enable to not answer id.server and hostname.bind queries.
hide-identity: yes
# enable to not answer version.server and version.bind queries.
hide-version: yes
# Will trust glue only if it is within the servers authority.
# Harden against out of zone rrsets, to avoid spoofing attempts.
# Hardening queries multiple name servers for the same data to make
# spoofing significantly harder and does not mandate dnssec.
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the
# zone becomes bogus. Harden against receiving dnssec-stripped data. If you
# turn it off, failing to validate dnskey data for a trustanchor will trigger
# insecure mode for that zone (like without a trustanchor). Default on,
# which insists on dnssec data for trust-anchored zones.
harden-dnssec-stripped: yes
# Use 0x20-encoded random bits in the query to foil spoof attempts.
# http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
# While upper and lower case letters are allowed in domain names, no significance
# is attached to the case. That is, two names with the same spelling but
# different case are to be treated as if identical. This means calomel.org is the
# same as CaLoMeL.Org which is the same as CALOMEL.ORG.
use-caps-for-id: yes
# the time to live (TTL) value lower bound, in seconds. Default 0.
# If more than an hour could easily give trouble due to stale data.
cache-min-ttl: 3600
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl: 86400
# perform prefetching of close to expired message cache entries. If a client
# requests the dns lookup and the TTL of the cached hostname is going to
# expire in less than 10% of its TTL, unbound will (1st) return the ip of the
# host to the client and (2nd) pre-fetch the dns request from the remote dns
# server. This method has been shown to increase the amount of cached hits by
# local clients by 10% on average.
prefetch: yes
# number of threads to create. 1 disables threading. This should equal the number
# of CPU cores in the machine. Our example machine has 4 CPU cores.
num-threads: 4
## Unbound Optimization and Speed Tweaks ###
# the number of slabs to use for cache and must be a power of 2 times the
# number of num-threads set above. more slabs reduce lock contention, but
# fragment memory usage.
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8
# Increase the memory size of the cache. Use roughly twice as much rrset cache
# memory as you use msg cache memory. Due to malloc overhead, the total memory
# usage is likely to rise to double (or 2.5x) the total cache memory. The test
# box has 4gig of ram so 256meg for rrset allows a lot of room for cacheed objects.
rrset-cache-size: 256m
msg-cache-size: 128m
# buffer size for UDP port 53 incoming (SO_RCVBUF socket option). This sets
# the kernel buffer larger so that no messages are lost in spikes in the traffic.
so-rcvbuf: 1m
## Unbound Optimization and Speed Tweaks ###
# Enforce privacy of these addresses. Strips them away from answers. It may
# cause DNSSEC validation to additionally mark it as bogus. Protects against
# 'DNS Rebinding' (uses browser as network proxy). Only 'private-domain' and
# 'local-data' names are allowed to have these private addresses. No default.
private-address: 192.168.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
# Allow the domain (and its subdomains) to contain private addresses.
# local-data statements are allowed to contain private addresses too.
private-domain: "home.lan"
# If nonzero, unwanted replies are not only reported in statistics, but also
# a running total is kept per thread. If it reaches the threshold, a warning
# is printed and a defensive action is taken, the cache is cleared to flush
# potential poison out of it. A suggested value is 10000000, the default is
# 0 (turned off). We think 10K is a good value.
unwanted-reply-threshold: 10000
# IMPORTANT FOR TESTING: If you are testing and setup NSD or BIND on
# localhost you will want to allow the resolver to send queries to localhost.
# Make sure to set do-not-query-localhost: yes . If yes, the above default
# do-not-query-address entries are present. if no, localhost can be queried
# (for testing and debugging).
do-not-query-localhost: no
# File with trusted keys, kept up to date using RFC5011 probes, initial file
# like trust-anchor-file, then it stores metadata. Use several entries, one
# per domain name, to track multiple zones. If you use forward-zone below to
# query the Google DNS servers you MUST comment out this option or all DNS
# queries will fail.
# auto-trust-anchor-file: "/var/unbound/etc/root.key"
# Should additional section of secure message also be kept clean of unsecure
# data. Useful to shield the users of this validator from potential bogus
# data in the additional section. All unsigned data in the additional section
# is removed from secure messages.
val-clean-additional: yes
# Blocking Ad Server domains. Google's AdSense, DoubleClick and Yahoo
# account for a 70 percent share of all advertising traffic. Block them.
# local-zone: "doubleclick.net" redirect
# local-data: "doubleclick.net A 127.0.0.1"
# local-zone: "googlesyndication.com" redirect
# local-data: "googlesyndication.com A 127.0.0.1"
# local-zone: "googleadservices.com" redirect
# local-data: "googleadservices.com A 127.0.0.1"
# local-zone: "google-analytics.com" redirect
# local-data: "google-analytics.com A 127.0.0.1"
# local-zone: "ads.youtube.com" redirect
# local-data: "ads.youtube.com A 127.0.0.1"
# local-zone: "adserver.yahoo.com" redirect
# local-data: "adserver.yahoo.com A 127.0.0.1"
# local-zone: "ask.com" redirect
# local-data: "ask.com A 127.0.0.1"
# Unbound will not load if you specify the same local-zone and local-data
# servers in the main configuration as well as in this "include:" file. We
# suggest commenting out any of the local-zone and local-data lines above if
# you suspect they could be included in the unbound_ad_servers servers file.
#include: "/etc/unbound/unbound_ad_servers"
# locally served zones can be configured for the machines on the LAN.
local-zone: "home.lan." static
local-data: "firewall.home.lan. IN A 10.0.0.1"
local-data: "laptop.home.lan. IN A 10.0.0.2"
local-data: "xboxone.home.lan. IN A 10.0.0.3"
local-data: "ps4.home.lan. IN A 10.0.0.4"
local-data: "dhcp5.home.lan. IN A 10.0.0.5"
local-data: "dhcp6.home.lan. IN A 10.0.0.6"
local-data: "dhcp7.home.lan. IN A 10.0.0.7"
local-data-ptr: "10.0.0.1 firewall.home.lan"
local-data-ptr: "10.0.0.2 laptop.home.lan"
local-data-ptr: "10.0.0.3 xboxone.home.lan"
local-data-ptr: "10.0.0.4 ps4.home.lan"
local-data-ptr: "10.0.0.5 dhcp5.home.lan"
local-data-ptr: "10.0.0.6 dhcp6.home.lan"
local-data-ptr: "10.0.0.7 dhcp7.home.lan"
# Unbound can query your NSD or BIND server for private domain queries too.
# On our NSD page we have NSD configured to serve the private domain,
# "home.lan". Here we can tell Unbound to connect to the NSD server when it
# needs to resolve a *.home.lan hostname or IP.
#
# private-domain: "home.lan"
# local-zone: "0.0.10.in-addr.arpa." nodefault
# stub-zone:
# name: "home.lan"
# stub-addr: 10.0.0.111@53
# If you have an internal or private DNS names the external DNS servers can
# not resolve, then you can assign domain name strings to be redirected to a
# seperate dns server. For example, our comapny has the domain
# organization.com and the domain name internal.organization.com can not be
# resolved by Google's public DNS, but can be resolved by our private DNS
# server located at 1.1.1.1. The following tells Unbound that any
# organization.com domain, i.e. *.organization.com be dns resolved by 1.1.1.1
# instead of the public dns servers.
#
# forward-zone:
# name: "organization.com"
# forward-addr: 1.1.1.1 # Internal or private DNS
# Use the following forward-zone to forward all queries to Google DNS,
# OpenDNS.com or your local ISP's dns servers for example. To test resolution
# speeds use "drill calomel.org @8.8.8.8" and look for the "Query time:" in
# milliseconds.
#
forward-zone:
name: "."
forward-addr: 1.1.1.1@53#one.one.one.one
forward-addr: 8.8.8.8@53#dns.google
forward-addr: 9.9.9.9@53#dns.quad9.net
forward-addr: 1.0.0.1@53#one.one.one.one
forward-addr: 8.8.4.4@53#dns.google
forward-addr: 149.112.112.112@53#dns.quad9.net
#
#
## Authoritative, validating, recursive caching DNS
## unbound.conf -- https://calomel.org
Calomel.org propose un OpenBSD Pf Firewall "how to" ( pf.conf ) si vous en avez besoin. Nous couvrons un exemple d'ordonnanceur HFSC avec une file d'attente de priorité DNS intégrée dans un ensemble de règles pf.conf fonctionnelles.
Unbound est le parfait soldat de première ligne pour les requêtes DNS des clients LAN. Il est rapide, fiable, stable et très sûr. BIND (named) ou NSD (Name Server Daemon) peuvent être conservés sur le réseau dorsal pour servir de DNS faisant autorité au cluster Unbound. De cette façon, vous gardez vos données DNS primaires séparées et non encombrées sur le serveur BIND ou NSD pendant que les serveurs du Unbound cluster se chargent de la résolution, de la mise en cache et de la validation des zones pour les clients.
L'idée est d'avoir quelques serveurs DNS de validation, récursifs et de mise en cache de Unbound que les clients du réseau local peuvent interroger. Utilisez ensuite BIND (named) comme serveur faisant autorité, qui ne peut résoudre que les noms internes du réseau local. Les clients du réseau local n'accéderont JAMAIS au serveur DNS BIND et BIND ne sortira jamais sur l'Internet. La seule tâche de BIND est de servir les noms internes au groupe de serveurs DNS non liés. Le cluster Unbound desservira tous les clients du réseau local. Si Unbound doit résoudre un ip privé, il demandera au serveur BIND des ips et mettra ensuite la réponse en cache. Si le client a besoin d'une adresse IP externe, par exemple de google.com ou cnn.com, Unbound interrogera récursivement les serveurs DNS racine d'Internet et mettra la réponse en cache.
Voici un schéma ASCII approximatif de la configuration. Les clients LAN sont toutes les machines internes du réseau local (LAN). Le DNS Internet est en fait n'importe quel serveur DNS externe. Les entrées pour Unbound #1 à #3 sont des machines séparées sur lesquelles tourne Unbound. La dernière machine est le DNS de réseau local privé BIND.
INTERNET DNS
|
|
-- Unbound #1 --
/ \ private authoritative only
LAN Clients -- --- Unbound #2 -- -- BIND or NSD dns server
\ / ( 10.0.0.111 )
-- Unbound #3 --
La configuration est assez simple. Prenez d'abord une copie de l'exemple non lié n°3 appelé "DNS autoritaire, validant, récursif en cache" du dessus. Nous allons ajouter des directives au bas de cette configuration. Nous avons juste besoin d'ajouter les directives stub-zone pour tous les noms internes que nous voulons non liés pour demander à BIND. Toute zone ne pointant pas vers notre serveur faisant autorité sera envoyée aux serveurs DNS racine pour obtenir une réponse. En outre, puisque BIND sera notre serveur d'authentification, vous pouvez commenter n'importe quelle directive de zone locale, de données locales et de données locales-ptr.
Disons que notre serveur privé NSD ou BIND fait autorité pour ce domaine interne du réseau local :
- home.lan
Nous devons dire aux serveurs du cluster Unbound que s'ils recherchent le domaine privé home.lan, ils doivent demander au serveur DNS faisant autorité, sinon aller vérifier auprès des serveurs DNS racine. L'IP du serveur NSD est 10.0.0.111 comme dans le diagramme ASCII.
Faites particulièrement attention à la directive "stub-zone" que nous utilisons. La stub-zone n'est utilisée que pour diriger les requêtes vers un serveur faisant autorité comme un serveur NSD dns. La directive forward-zone ne peut être utilisée que pour diriger les requêtes vers un serveur dns de résolution comme OpenDNS.com ou le serveur de mise en cache de votre FAI local. Les deux ne sont pas interchangeables.
NOTE : Nous utiliserons la configuration NSD sur la page NSD (Name Server Daemon) Tutorial avec cet exemple.
## Add this to the bottom of example #2's unbound.conf configuration
## Check out our NSD Tutorial at https://calomel.org/nsd_dns.html
# This local-zone line will tell unbound that private addresses like
# 10.0.0.0/8 can send queries to a stub zone authoritative server like NSD.
local-zone: "10.in-addr.arpa." nodefault
# This is the FORWARD lookup stub zone pointing to the NSD authoritative
# server. When a client queries for firewall.home.lan the question is sent
# to the NSD server located at 10.0.0.111 and NSD returns the answer
# "10.0.0.1".
stub-zone:
name: "home.lan"
stub-addr: 10.0.0.111
# This is the REVERSE (rDNS) dns lookup for the home.lan zone. When a client
# asks for the hostname belonging to the ip address 10.0.0.1 the NSD
# authoritative server at 10.0.0.111 will send back the answer
# "firewall.home.lan".
stub-zone:
name: "10.in-addr.arpa."
stub-addr: 10.0.0.111
C'est à peu près tout. Un client qui demande un nom d'hôte dns interne comme laptop.home.lan.lan fera une requête Unbound au serveur NSD (10.0.0.111) ; la réponse sera mise en cache par Unbound pour les requêtes ultérieures. Toute autre requête pour un nom d'hôte externe (calomel.org par exemple) provenant d'un client de réseau local fera en sorte que Unbound se rende sur les serveurs Internet pour obtenir la réponse. Les clients peuvent désormais interroger le cluster Unbound pour n'importe quel nom d'hôte et nous n'avons pas à nous inquiéter de l'abus ou de la surcharge de nos serveurs DNS primaires. Cette configuration est principalement conçue pour isoler le serveur faisant autorité de lui-même et garder la configuration DNS primaire sûre.
Dnsspoof est la possibilité de répondre avec une adresse IP qui n'est normalement PAS associée à un nom d'hôte. Il s'agit d'un type limité de fonctionnalité "Split horizon". La forme entièrement généralisée du DNS à horizon partagé permet au numéro IP associé à un nom d'hôte de varier de manière dépendante du réseau à partir duquel la requête DNS est effectuée. Unbound n'offre pas une prise en charge complète du DNS à horizon partagé car il ne modifie pas sa réponse en fonction du réseau d'interrogation. Mais Unbound prend en charge l'usurpation de DNS, en modifiant la réponse normale à une requête DNS sur tous les réseaux desservis par Unbound. Par exemple, supposons que vous ayez un serveur web accessible aux réseaux interne et externe. Le serveur web se trouve dans une DMZ sur le réseau local interne. Le public utilise le nom d'hôte externe webserver.example.com qui se résout à l'ip 111.222.333.444 qui traverse un pare-feu jusqu'à la DMZ. Le problème se pose lorsque les clients de votre réseau local interne souhaitent également utiliser le serveur web.example.com . Le trafic des clients internes doit alors sortir du pare-feu, passer par le routeur et revenir dans la DMZ en passant par le pare-feu, ce qui ajoute beaucoup de trafic inutile à la connexion externe. Ne serait-il pas agréable de simplement envoyer les clients internes directement à l'adresse ip interne de la DMZ ?
Nous pouvons configurer Unbound pour spoofer la requête dns des clients LAN de sorte qu'au lieu d'obtenir l'adresse externe pour le nom externe, ils reçoivent une adresse IP interne pour le nom externe. webserver.example.com qui normalement se résout en 111.222.333.444 se résout maintenant en 10.0.0.222 . 10.0.0.222 serait le même serveur web qui est situé à l'intérieur du pare-feu dans une DMZ.
## DnsSpoof of webserver.example.com (exact domain name match)
local-data: "webserver.example.com. IN A 10.0.0.222"
Le DnsSpoof'ing peut également être utile pour empêcher les clients du réseau local de se rendre sur des sites qui ne sont pas appropriés ou qui ne sont pas autorisés sur votre réseau. Vous pouvez également utiliser cette méthode pour empêcher vos clients de se rendre sur des serveurs publicitaires. Par exemple, nous ne voulons pas que quelqu'un aille sur facebook.com ou doubleclick.net, ou même sur l'un de ses sous-domaines, mais nous lui donnons l'adresse IP 10.0.0.111 de notre serveur web local pour lui expliquer nos conditions d'utilisation d'Internet.
## DnsSpoof of unwanted or restricted sites
local-zone: "doubleclick.net" redirect
local-data: "doubleclick.net A 10.0.0.111"
local-zone: "facebook.com" redirect
local-data: "facebook.com A 10.0.0.111"
La requête dns par un client interne entraînerait alors les différences suivantes. Notez que l'utilisation de la méthode de redirection redirigera désormais tous les sous-domaines vers 10.0.0.111 également.
## Normal DNS resolution for facebook.com
$ host facebook.com
facebook.com has address 69.63.189.16
facebook.com has address 69.63.181.12
facebook.com has address 69.63.189.11
facebook.com mail is handled by 10 smtpin.mx.facebook.com.
## DnsSpoof of facebook.com
$ host facebook.com
facebook.com has address 10.0.0.111
## Sub domains are also redirected
$ host ads.facebook.com
ads.facebook.com has address 10.0.0.111
Yoyo.org fournit une liste de serveurs publicitaires connus dans un fichier texte pratique qui est mis à jour périodiquement et pré-formaté pour le non-lié. La liste configurera Unbound pour rediriger les noms d'hôte des serveurs publicitaires vers localhost (127.0.0.1). Utilisez curl pour télécharger la liste dans un nouveau fichier appelé "unbound_ad_servers" et sed pour nettoyer les en-têtes HTML dans la sortie. Une fois ce fichier en place, il vous suffit d'ajouter une directive "include :" à votre unbound.conf pointant sur le chemin complet du fichier "unbound_ad_servers". Unbound redirigera alors tous les 2400+ serveurs de publicité vers localhost en gardant la plupart, sinon toute la publicité loin de vos systèmes. Simple, mais puissant.
NOTE : Assurez-vous de supprimer toute entrée "local-zone" qui pourrait être dupliquée dans la liste des serveurs de publicité Yoyo. Par exemple, si vous avez "local-zone" : "doubleclick.net" redirect" dans le fichier unbound.conf et que Yoyo a la même "local-zone" : "doubleclick.net" redirect" dans leur liste, alors Unbound ne pourra pas démarrer à cause du conflit.
# download the anti-ad server list to Unbound's configuration directory.
curl -sS -L --compressed "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext" > /etc/unbound/unbound_ad_servers
# then add an include line to your unbound.conf pointing to the full path of
# the unbound_ad_servers file:
#
# include: /etc/unbound/unbound_ad_servers
#
Le temps de fonctionnement du système est-il critique pour le fonctionnement de Unbounds ?
Oui. Unbound est très paranoïaque au sujet de ses enregistrements DNS. Si un enregistrement est périmé, ou pire encore, si l'enregistrement existe à une date ultérieure, Unbound ne résoudra pas ce domaine correctement.
Un problème courant est que vous devez redémarrer le système et que l'heure du BIOS est incorrecte. Unbound est alors lancé au démarrage et utilise l'heure système actuelle incorrecte. Vous devez alors régler l'heure correcte manuellement. Maintenant, soit tous vos enregistrements dns sont expirés parce que l'heure a été fixée dans le passé, soit les enregistrements sont illégaux puisque l'heure est fixée dans le futur.
Assurez-vous que l'heure système de votre machine est aussi correcte que possible en utilisant le NTPD d'un serveur de temps GPS. Démarrez ensuite Unbound lorsque l'heure est correcte.
Quel générateur de nombres aléatoires PRNG utilise Unbound ?
Unbound utilise un générateur de nombres aléatoires de force cryptographique. Le générateur arc4random() d'OpenBSD est utilisé ou Yarrow sur FreeBSD. Cela signifie que prédire les nombres aléatoires générés par Unbound équivaut à craquer un code de chiffrement. Le générateur de nombres aléatoires est ensemencé d'entropie. L'entropie réelle du système /dev/random est utilisée pour amorcer le générateur de nombres aléatoires. Ainsi, les valeurs de départ du générateur de nombres aléatoires ne peuvent pas être facilement prédites. L'installation du paquetage OpenBSD de Unbound utilise /dev/arandom à la place pour une entropie plus aléatoire et une création plus rapide de l'amorçage.
Qu'est-ce que la capitalisation aléatoire dns-0x20 ?
La capitalisation aléatoire est également appelée dns-0x20. Il s'agit d'une méthode expérimentale de résilience qui utilise des lettres majuscules et minuscules dans le nom d'hôte de la question pour obtenir un caractère aléatoire. En moyenne, on ajoute environ 7 ou 8 bits d'entropie. Cette méthode doit actuellement être activée manuellement par l'administrateur du dns, car il se peut que 0,4 % des domaines n'obtiennent pas de réponse en raison de l'absence de support du côté du serveur faisant autorité. Dans notre second exemple, nous activons la directive "use-caps-for-id : yes" pour une meilleure sécurité en utilisant dns-0x20.
Tout cela signifie que calomel.org est identique à CaLOMeL.Org qui est identique à CALOMEL.ORG. Lorsqu'Unbound envoie une requête à un serveur distant, il envoie la chaîne du nom d'hôte en caractères aléatoires supérieurs et inférieurs. Le serveur distant doit résoudre le nom d'hôte comme si tous les caractères étaient des minuscules. Le serveur distant doit ensuite renvoyer la requête à Unbound en utilisant les mêmes caractères aléatoires supérieurs et inférieurs que ceux envoyés par Unbound. Si les caractères du nom d'hôte dans la réponse sont au même format que la requête, alors le contrôle dns-0x20 est satisfait.
Les attaquants qui espèrent empoisonner un cache DNS non lié doivent donc deviner l'encodage mixte de la requête et le moment de la réponse dns de retour en plus de tous les autres champs requis dans une attaque d'empoisonnement DNS. dns-0x20 augmente considérablement la difficulté de l'attaque.
Comment puis-je interroger un serveur DNS pour connaître le nom et la version de son logiciel ?
Utilisez la commande "dig". La première ligne interrogera le serveur dns local ou le résolveur situé chez localhost (127.0.0.1). Cet exemple montre la réponse de la version 1.4.7 de Unbound. Les lignes suivantes sont des exemples d'autres serveurs DNS. BTW, si vous activez les directives dans Unbound pour cacher l'identité (hide-identity et hide-version) du serveur comme nous le faisons dans notre deuxième exemple, la réponse sera complètement vide.
## Unbound version v1.4.7
dig +short version.bind chaos txt
"unbound 1.4.7"
## Verizon running Vantio v4.4.0.2
dig @151.197.0.38 +short version.bind chaos txt
"Nominum Vantio 4.4.0.2"
## Level 3 is more paranoid.
dig @4.2.2.1 +short version.bind chaos txt
"If you have a legitimate reason for requesting this
info, please contact hostmaster@Level3.net"
Comment puis-je facilement surveiller le trafic DNS en temps réel ?
Essayez un programme appelé "dnstop". Il est disponible par l'intermédiaire de la plupart des gestionnaires de paquets. Une fois installé, il suffit d'exécuter le binaire avec l'argument de l'interface que vous voulez surveiller le trafic DNS. Par exemple, nous exécuterons "dnstop em0" pour surveiller le trafic sur l'interface em0 externe basée sur Intel. Il y a quelques pages d'options dans dnstop qui peuvent être accessibles en utilisant les touches numériques. La page de l'auteur contient quelques exemples de DnsTop screen output looks like.
Le basculement dans /etc/resolv.conf est trop lent. Que puis-je faire ?
Le délai normal de basculement d'un serveur de noms à un autre dans le fichier /etc/resolv.conf est de 5 secondes. Ce délai est un peu trop long. Vous pouvez utiliser la directive "options" pour fixer le délai d'attente à 3 dixièmes de seconde. Cet exemple permet également de "tourner" pour équilibrer la charge des requêtes de serveur de noms, de régler les tentatives sur une seule pour essayer un serveur de noms une seule fois avant de passer à la suivante et de fixer le seuil du nombre de points qui doivent apparaître dans un nom avant qu'une première requête absolue ne soit effectuée.
domain domain.lan
search domain.lan domain.lan2 domain.lan3 domain.lan4
nameserver 192.168.0.1
nameserver 192.168.0.2
options ndots:1 timeout:0.3 attempts:1 rotate
Comment puis-je évaluer correctement la qualité de l'information sur les produits non consolidés ?
Ceci est une réponse sur la liste de diffusion de Unbound de Wijngaards, un des développeurs, à un utilisateur concernant les tests de performance de Unbound et l'obtention de résultats corrects. Nous avons inclus le fil de discussion dans son intégralité.
...Question : Je teste actuellement Unbound dans le cadre d'un projet en cours, mais je constate des résultats très différents en comparant les statistiques de contrôle de Unbound à ce que montrent les résultats de Queryperf. Par exemple, j'ai enregistré la sortie du total des requêtes .num.dans un fichier chaque seconde et j'ai calculé le résultat moyen qui montre 9474 requêtes par seconde, queryperf montre 6945 qps. Les deux résultats proviennent de la même charge de test.
...Réponse :
Cela peut vous surprendre, mais il s'agit en fait d'une question fréquemment posée au serveur non lié par des personnes qui tentent de mesurer sa vitesse. (Vantardise : c'est à cause de sa vitesse).
Je vois deux explications. La première, et d'après mon expérience avec d'autres personnes qui font des benchmarks, c'est que le serveur non lié surpasse le queryperf. La seconde est un dépassement de tampon.
- Unbound est plus performant que queryperf. Ainsi, il renvoie plus que ce que queryperf peut gérer. La mesure que vous avez obtenue de queryperf est la vitesse de queryperf lui-même.
- Les dépassements de tampon peuvent être constatés avec netstat -su. Les options so-rcvbuf et so-sndbuf peuvent vous aider à stopper les dépassements de tampon pour les non-liés.
Pour des résultats plus rapides, http://unbound.net/documentation/howto_optimise.html
...Question : Quelle est la bonne façon de surveiller et d'évaluer les requêtes par seconde sur un serveur non lié ?
...Réponse : Comme les requêtes non liées sont plus performantes que les requêtes envoyées par l'expéditeur, vous devez rendre votre expéditeur plus fort. Commencez par utiliser son propre ordinateur pour l'expéditeur (ne l'exécutez pas sur le serveur lui-même, ce serveur est occupé avec le unbound, et vous avez configuré num-threads au nombre de cpus dans /proc/cpuinfo pour qu'il utilise tous les CPU, n'est-ce pas ? Vous voulez également inclure la vitesse de la pile IP dans le résultat). Ajoutez ensuite un autre ordinateur qui exécute queryperf (vous pouvez additionner les qps de résultat pour les deux ordinateurs qui exécutent queryperf). Ajoutez d'autres ordinateurs jusqu'à ce que le qps ne monte plus, ou descende un peu (un déni de service sur le serveur non lié). C'est la vitesse mesurée. Jan-Piet Mens (qui a écrit un livre à ce sujet) m'a dit qu'il a fini par avoir une classe entière d'ordinateurs exécutant queryperf.
...Conclusion:
Les serveurs que j'ai testés sont des Intel E4500 avec 2 Go de RAM et des cartes réseau gigabit Intel. Ils ne sont cependant que sur des ports de 100 mbit et sont acheminés par l'intermédiaire de Cisco IP SLA. Le client de test se trouve sur un sous-réseau entièrement séparé et est un boîtier opteron à 8 cœurs avec une carte réseau Intel. Cependant, j'ai également exécuté queryperf à partir de plusieurs sources à la fois en utilisant des machines virtuelles.
Les requêtes réelles dans mon fichier de données sont capturées à partir du trafic DNS réel dans notre centre de données, environ 50% des requêtes finissent par atteindre le cache. Je peux également voir les effets de la mise en cache dans mes graphiques.
Nous avons fini par modifier un peu le fichier unbound.conf et avons changé les paramètres suivants, ce qui a plus que doublé les performances, passant de 8,8 k qps [requêtes par seconde] à plus de 20 k.
# outgoing-range: 4096
outgoing-range: 32768
# so-rcvbuf: 0
so-rcvbuf: 32m
# msg-cache-size: 4m
msg-cache-size: 256m
num-queries-per-thread: 4096
# rrset-cache-size: 4m
rrset-cache-size: 256m
# infra-cache-numhosts: 10000
infra-cache-numhosts: 100000
Qu'est-ce que le DNS Cache Poisoning ?
L'empoisonnement d'un résolveur DNS désigne l'acte d'insérer des données fausses, souvent malveillantes, dans le cache du résolveur. Cela peut entraîner la redirection des visiteurs d'un site web (par exemple leur site bancaire) qu'ils pensaient visiter vers un autre site web, par exemple un site de phishing.
Le DnsSpoof est-il également considéré comme un empoisonnement du cache ? En fait, c'est le cas. La différence est que l'empoisonnement est l'acte d'insérer de mauvaises données de manière malveillante et que le dnsspoof'ing est l'insertion de données que nous connaissons. Il s'agit d'une distinction très fine qui dépend de la personne qui interroge les données.
Unbound met en œuvre un certain nombre de méthodes pour ajouter des bits aléatoires afin de sécuriser les requêtes contre une déviation malveillante. Le moyen le plus important pour ajouter du caractère aléatoire est de faire varier les numéros de port à partir desquels la question est posée, un autre moyen est d'utiliser un hack qui randomise les bits inutilisés dans le nom de la requête. Unbound utilise 16 bits pour la randomisation du port. Pour être précis, environ 60000 ports aléatoires, en évitant les ports inférieurs à 1024 et en évitant les ports UDP alloués par l'IANA pour éviter l'instabilité du système du serveur. La randomisation des ports utilise le même générateur de nombres aléatoires que l'ID. Unbound veille à ce qu'un port tiré au hasard soit utilisé pour une requête. Ainsi, chaque requête obtient un numéro de port fraîchement tiré au hasard.
Une véritable protection, où vous n'êtes pas soumis aux caprices du hasard, est obtenue en utilisant le DNSSEC. La DNSSEC utilise des signatures numériques pour protéger les données. Avec la DNSSEC, il n'y a aucun risque d'empoisonnement, indépendamment du nombre de bits aléatoires utilisés. Unbound met en œuvre la norme DNSSEC comme spécifié dans les RFC ( RFC4034, RFC4035 ). Unbound peut agir en tant que validateur et peut ainsi vérifier les signatures numériques jointes dans les réponses. Bien entendu, le propriétaire du nom de domaine doit avoir inséré ces signatures numériques en premier lieu. En l'absence de DNSSEC, unbound tente d'offrir une très bonne sécurité. Sans signatures numériques, la randomisation et le filtrage sont actuellement les seules options.